METHOD AND APPARATUS FOR MANAGING DIGITAL 
CONTENT USAGE RIGHTS 



RELATED APPLICATION DATA 

This application claims benefit of U.S. provisional application Serial No. 
60/261,753 filed on January 17, 2001, the disclosure of which is incorporated 
herein by reference. 

BACKGROUND OF THE INVENTION 

The invention relates to usage rights for controlling the distribution and 
use of digital content, and more particularly to a method and an apparatus for 
managing usage rights to be associated with content. 

The Internet is a worldwide network of computers linked together by 
various hardware communication links all running a standard suite of 
protocols known as TCP/IP (transmission control protocol/Internet protocol). 
The growth of the Internet over the last several years has been explosive, 
fueled in the most part by the widespread use of software tools (known as 
"browsers") which allow both HTML (hypertext markup language) viewing 
and HTTP (hypertext transfer protocol) navigation. Browsers allow a simple 
GUI (graphical user interface) to be used to communicate over the Internet. 
Browsers generally reside on the computer used to access content on the 
Internet, i.e. the client computer. HTTP is a component on top of TCP/IP 
and provides users access to documents of various formats using the 
standard page description language known as HTML and more recently XML 
(extensible markup language) and XHTML (extensible hypertext markup 
language), a reformulation of HTML into XML. The collection of servers on 
the Internet using HTML/HTTP has become known as the "World Wide Web" 
or simply the "Web." 

Through HTML, XHTML, and interactive programming protocols, the 
author of content is able to make the content available to others by placing 
the content, in the form of a Web page, on an Internet Web server. The 
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network path to the server is identified by a URL (Uniform Resource Locator) 
and, generally, any client running a Web browser can access the Web 
server by using the URL. A client computer running a browser can request a 
display of a Web page stored on a Web server by issuing a URL request 
through the Internet to the Web in a known manner. 

Since the Web utilizes standard protocols and a standard rendering 
engine, i.e. the rendering engine of the browser, the Web has become 
ubiquitous. One of the primary applications of the Web has been distribution 
of content in the form of documents. A "document", as the term is used 
herein, is any unit of information subject to distribution or transfer, including 
but not limited to correspondence, books, magazines, journals, newspapers, 
other papers, software, photographs and other images, audio and video clips, 
and other multimedia presentations. A document may be embodied in printed 
form on paper, as digital data on a storage medium, or in any other known 
manner on a variety of media. 

However, one of the most important issues impeding the widespread 
distribution of digital documents, i.e. documents in forms readable by 
computers, via electronic means, and the Internet in particular, is the current 
lack of protection of the intellectual property rights of content owners during 
the distribution and use of those digital documents. Efforts to resolve this 
problem have been termed "Intellectual Property Rights Management" 
("IPRM"), "Digital Property Rights Management" ("DPRM"), "Intellectual 
Property Management" ("IPM"), "Rights Management" ("RM"), and "Electronic 
Copyright Management" ("ECM"), collectively referred to as "Digital rights 
management (DRM)" herein. 

In the world of printed documents, a work created by an author is 
usually provided to a publisher, which formats and prints numerous copies of 
the work. The copies are then sent by a distributor to bookstores or other 
retail outlets, from which the copies are purchased by end users. While the 
low quality of copying and the high cost of distributing printed material have 
served as deterrents to unauthorized copying of most printed documents, it is 
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far too easy to copy, modify, and redistribute unprotected digital documents. 
Accordingly, some method of protecting digital documents is necessary to 
make it more difficult to copy and distribute them without authorization. 

Unfortunately, it has been widely recognized that it is difficult to 
prevent, or even deter people from making unauthorized distributions of 
electronic documents within current general-purpose computing and 
communications systems such as personal computers, workstations, and 
other devices connected over communications networks, such as local area 
networks (LANs), intranets, and the Internet. Many attempts to provide 
hardware-based solutions to prevent unauthorized copying have proven to be 
unsuccessful. The proliferation of "broadband" communications technologies 
will render it even more convenient to distribute large documents 
electronically, including video files such as full length motion pictures, and 
thus will remove any remaining deterrents to unauthorized distribution of 
documents. Accordingly, DRM technologies are becoming very useful. 

Two basic schemes have been employed to attempt to solve the 
document protection problem: secure containers and trusted systems. A 
"secure container" (or simply an encrypted document) offers a way to keep 
document contents encrypted until a set of authorization conditions are met 
and some copyright terms are honored (e.g., payment for use). After the 
various conditions and terms are verified with the document provider, the 
document is released to the user in clear form. Commercial products such as 
Cryptolopes by IBM™ and by InterTrust's™ Digiboxes fall into this category. 
Clearly, the secure container approach provides a solution to protecting the 
document during delivery over insecure channels, but does not provide any 
mechanism to prevent legitimate users from obtaining the clear document and 
then using and redistributing it in violation of content owners' intellectual 
property. 

Cryptographic mechanisms are typically used to encrypt (or "encipher") 
documents that are then distributed and stored publicly, and ultimately 
privately deciphered , i.e. unencrypted, by authorized users. This provides a 
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basic form of protection during document delivery from a document distributor 
to an authorized user over a public network, as well as during document 
storage on an insecure medium. 

In the "trusted system" approach, the entire system is responsible for 
preventing unauthorized use and distribution of the document. Building a 
trusted system usually entails introducing new hardware such as a secure 
processor, secure storage and secure rendering devices. This also requires 
that all software applications that run on trusted systems be certified to be 
trusted. While building tamper-proof trusted systems is still a real challenge to 
existing technologies, current market trends suggest that open and untrusted 
systems such as PC's and workstations using browsers to access the Web, 
will be the dominant systems used to access copyrighted documents. In this 
sense, existing computing environments such as PC s and workstations 
equipped with popular operating systems (e.g., Windows™, Linux™, and 
UNIX) and rendering applications such as browsers are not trusted systems 
and cannot be made trusted without significantly altering their architectures. 
Of course, alteration of the architecture defeats a primary purpose of the Web, 
i.e. flexibility and compatibility. 

U.S. patent no. 5,715,403, the disclosure of which is incorporated 
herein by reference, discloses a system for controlling the distribution of 
digital documents. Each rendering device has a repository associated 
therewith. Usage rights labels are associated with digital content. The labels 
include usage rights that specify a manner of use of the content and any 
conditions precedent for exercising the manner of use. U.S. patent no. 
5,052,040 discloses the use of a label prefixed to digital files so that different 
users can have specific encryption capability and rights with respect to the 
same file. 

The proliferation of the Web, and its usefulness in document 
distribution, makes it desirable to apply DRM features to many documents in 
various systems. However, there are no universally accepted formats or 
mechanisms for creating usage rights, associating usage rights with content, 
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or generally managing usage rights. Accordingly, applications form various 
vendors are not compatible with usage rights associated with various 
documents in a consistent manner. 

SUMMARY OF THE INVENTION 

The embodiment described below provides an easy to use application 
or GUI so any authorized user can create and mange usage rights. This is 
accomplished by providing an object oriented model that comprehends rights 
specification at different levels of the document life cycle (creation, 
distribution, retail, etc), and provides powerful capabilities (such as batch 
support and rights delegation). 

A first aspect of the invention is a system for manipulating and 
managing usage rights adapted to be associated with digital content. The 
system comprises a rights module operative to specify a manner of use, a 
conditions module operative to specify one or more conditions necessary for 
exercising a manner of use, and an offers module operative to combine one 
or more rights specified by said rights module and one or more conditions 
specified by the conditions module to create a rights offer object of usage 
rights and associated conditions necessary for exercising a manner of use 
indicated by the usage rights. 

A second aspect of the invention is a label for expressing usage rights 
adapted to be associated with digital content. The label comprises usage 
rights specifying a manner of use, conditions specifying one or more 
conditions necessary for exercising a manner of use, wherein one or more of 
said usage rights and one or more of said conditions are combined to create a 
rights offer object, and a label container including at least one rights offer 
object. 

BRIEF DESCRIPTION OF THE DRAWING 

The invention is described through preferred embodiments and the 
attached drawing in which: 
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Fig. 1 is a block diagram of a content distribution system that can be 
used with the preferred embodiment; 

Fig. 2 is schematic illustration of a rights label in accordance with the 
preferred embodiment; 

Fig. 3 is a block diagram of the editor of the preferred embodiment; 

Fig. 4 is an example of an offer creation and editing screen of the 
preferred embodiment; 

Fig. 5 is an example of a label creation and editing screen of the 
preferred embodiment; 

Fig. 6 is an example of a license editing screen of the preferred 
embodiment; 

Fig. 7 is an example of a simple edit screen of the preferred 
embodiment; 

Fig. 8 is an example of an advanced edit screen of the preferred 
embodiment; and 

Fig. 9 is an example of a label management screen of the preferred 
embodiment. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Fig. 1 is a block diagram of a system for the electronic distribution that 
can be used with the preferred embodiment. Author 110 creates original 
content and passes it to distributor 120 for distribution. Ordinarily, author 110 
is the creator of the content. However, the term "author" as used herein can 
be the creator, owner, editor, or other entity controlling the content or an agent 
(e.g. a publisher) of one of those entities. Also author 110 may distribute 
documents directly, without involving another party such as distributor 120, 
and thus the author and distributor may be the same entity. However, the 
division of functions set forth in Fig. 1 is efficient, as it allows author 1 10 to 
concentrate on content creation and not the administrative functions of 
distribution. Moreover, such a breakdown facilitates economies of scale by 
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permitting distributor 120 to associate with a number of authors 110. The term 
"document", as used herein, generally refers to any type of document, such as 
text, audio, or other data, including any encryption, formatting, or the like. The 
term "content", as used herein, generally refers to a document or any other 
object that can have usage rights associated therewith. For example the 
content can be a document service, such as a Web service defined by Web 
Service Description Language (WSDL) and published in a Uniform 
Description, Discovery, and Integration (UDDI) directory. 

Distributor 120 associates a rights label, which is described in detail 
below, with the content. The rights label can be registered with clearinghouse 
150 and stored in a label repository, such as a memory device associated 
with clearinghouse 150. The content can be stored in a content repository, 
such as a storage device associated with distributor 120. Alternatively, the 
label and content can be stored on the same device. Distributor 120 
distributes content to user 1 30, through a digital storefront on the Web or the 
like, upon request. In a typical electronic distribution model, the content is 
distributed in encrypted form. Distributor 120 encrypts the content with a 
random key and then encrypts the random key with a public key 
corresponding to user 130. Thus the encrypted document is customized 
solely for the particular user 1 30. User 1 30 is then able to use their private 
key to unencrypt the random key and use it to unencrypt and view the 
document. For example, PKI technology is used with the preferred 
embodiment. However, any other type of ciphering, encryption, 
watermarking, or other security or obfuscation methods can be used. 

The private key, or other identification information is issued to user 130 
upon purchase of an appropriate rights label (described in detail below) from 
clearinghouse 150. In particular, payment for the document is passed from 
user 130 to distributor 120 by way of clearinghouse 150 which collects 
requests from user 130 and from other users who wish to use particular 
content. Clearinghouse 150 also collects payment information, such as debit 
transactions, credit card transactions, or other known electronic payment 
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schemes, and forwards the collected payments as a payment batch to 
distributor 120. Of course, clearinghouse 150 may retain a share of the 
payment as a fee for the above-noted services. Distributor 120 may retain a 
portion of the batch payment from clearinghouse 150 for distribution services 
and forward a payment (for example royalties) to author 110. 

User 130 requests a rights label corresponding to desired content from 
clearinghouse 150 and provides clearinghouse 150 with information, such as 
credit card and charge authorization information, personal information, or the 
like to permit clearinghouse 150 to authorize user 130 in a known manner. 
Once user 130 has been authorized and obtained the rights label from 
clearinghouse 150, user 130 may request the associated content from 
distributor 120 by submitting the rights label, including authorization 
identification, such as a private key, obtained from clearinghouse 150. 
Distributor 120 parses the rights label to determine which content is 
associated therewith and permits the content to be decrypted and used in 
accordance with the usage rights in the rights label in a known manner. If the 
rights label is not presented, or the conditions thereof are not satisfied, the 
content is not made available for use. 

Each time user 130 requests a rights label corresponding to a 
document, an accounting message is sent to audit server 140 which ensures 
that each label request by user 130 matches with a subsequent document 
sent by distributor 120 to user 130. Accounting information is received by 
audit server 140 directly from distributor 120. Any inconsistencies are 
transmitted via a report to clearinghouse 150, which can then adjust the 
payment batches made to distributor 120 accordingly. This accounting 
scheme is present to reduce the possibility of fraud in electronic document 
distribution and to handle any time-dependent usage permissions that may 
result in charges that vary, depending on the duration or other extent of use. 
Audit server 140 and clearinghouse 150, in combination, can serve as 
transaction aggregator 160 which functions to aggregate plural transactions 
over a period of time, and charge distributor 120 in an appropriate manner to 
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reduce the accounting overhead of distributor 120. The model for electronic 
document distribution illustrated in Fig. 1 can be applied to distribution of 
documents using rights labels of the preferred embodiment disclosed herein. 

The preferred embodiment incorporates a model for usage rights 
specifications or "rights specifications." Software applications and user 
interfaces can be created to conform to the model to facilitate the workflow in 
creating a rights specification. As an example, the underlying mechanism can 
use a grammar, such as that disclosed in U.S. patent no. 5,715,403, U.S. 
provisional application Serial No. 60.261,753, the disclosure of which are 
incorporated herein by reference. The invention can be applied to any 
language or grammar for rights specifications. The term "rights specification" 
as used herein refers generally to the association of usage rights with content. 

The model includes four components, a rights component, a conditions 
component, an offer component, and a label component. Each component 
can be created by a corresponding software module. Of course, the modules 
need not be separate physical entities, or even separate lines of code, but are 
merely used as in the preferred embodiment a way of describing the 
functional aspect of the software used to create usage rights labels in 
accordance with the preferred embodiment. Each component is discussed in 
detailed below. 

Usage rights or "rights", specify manners of use. For example, a 
manner of use can include the ability to view, print, copy distribute or the like 
as set forth in U.S. patent no. 5,715,403 the disclosure of which is 
incorporated herein by reference. Rights can also be bundled as in "view and 
print." More sophisticated usage rights can be, for example, the right to sell if 
the principal is an intermediary such as a wholesaler. 

Conditions must be satisfied in order to exercise the manner of use in a 
specified usage right. For, example a condition may be the payment of a fee, 
submission of personal data, or any other requirement desired before 
permitting exercise of a manner of use. Conditions can also be "access 
conditions" for example, access conditions can apply to a particular group of 
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users, say students in a university, or members of a book club. In other 
words, the condition is that the user is a particular person or member of a 
particular group. Rights and conditions can exist as separate entities, but by 
themselves are not very useful. For example, a right, such as right to view 
content, can be specified, but without any association to conditions it is not 
very useful. 

Rights offers, or "offers" include a rights component and a conditions 
component and a relationship therebetween. Accordingly, an offer can 
present a choice that a consumer, i.e. user of content, can make. For 
example, and offer can be to view and print unlimited number of copies 
(usage rights) for a payment of $5.00 (condition). An offer can be created by 
selecting rights and the conditions that are associated with each right or 
bundle of rights. In more sophisticated examples, a rights offer could be, for 
example, an offer to allow the sale of 500 copies at a specified fee if the user 
is a wholesaler. 

Fig. 2 schematically illustrates rights label 200 in accordance with the 
preferred embodiment. Rights labels, or "labels" are collections of rights offers 
220. For example, label 100 can include one or more offers 220, and a user 
has the option to select any of the offers 220 to use the content in accordance 
with the usage rights 222 of the selected 220 offer after satisfying the 
conditions 224 of the selected offer 220. Labels 200 can be constructed by 
selecting one or more offers and bundling them together in a package. 

As noted above, rights and conditions, as distinct entities, are an 
abstract concept with little practical use. For example, distributors and the like 
do not generally need to create rights and conditions independently of offers. 
In the model of the preferred embodiment, the basic elements that are going 
to be used and reused are rights offers 220 and rights labels 200. Rights 
offers 220 are very useful because they form the basis for offering something, 
i.e. content for use. As noted above, an offer 220 can consist of a "bundle" of 
rights 222 and the condition 224 or conditions for that bundle. So the bundling 
of rights 222 can be accomplished when an offer 220 is created. For example, 
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as a single offer 220, a publisher may wish to provide both view and print 
together as usage rights 222. Conditions 224 can also be specified when 
offer 220 is created. Thus offer 220 precisely defines right 222 or a rights 
bundle and the associated condition 224 or conditions. Offers 220 have 
practical use independent of labels as will became apparent form the 
description below. 

The preferred embodiment permits manipulation of offers 220 in an 
object oriented manner. For example a distributor or author may create 
many offers 220 and keep them organized in a folder, i.e. directory, 
represented as a graphical object. The offers 220, as objects, may be named 
with descriptive practical names such as "Confidential Doc for Mgrs.ofr". Note 
that offer objects are denoted with the file extension ".ofr" in the preferred 
embodiment. However, any file extensions or nomenclature can be used to 
name offer objects. Offer objects, the corresponding graphical icon, and 
offers 220 themselves represent the same entity and thus will be collectively 
referred to as "offers 220." 

In order to be used to regulate the use of content, offers 220 should be 
associated with content. Rights labels 200, or "labels" specify the association 
of offers 220 to content. Labels 200 specify the digital content, through a link 
or the like known as content specification 226, and can also include metadata 
of the content. For example, metadata in a label can include the title of the 
content, the author, or any other relevant information. Further, labels 200 can 
specify, i. e., be associated with, portions of the content (as in a composite 
document) and can include metadata associated with each portion. Thus, a 
single label 200 can include metadata for the entirety of content and metadata 
for portions of the content. 

Content can be associated with one or more offers of a label. Further, 
labels can support "precedence rules" to facilitate specification. For example, 
if every portion of content has the same offer, the offer can be associated with 
the first portion of content. As objects, labels can be deleted, renamed, or 
organized in a folder as will become apparent from the disclosure below. 
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An editor, in the form of computer software to be run on a general 
purpose computer (such as a personal computer running the Microsoft 
Windows 2000™ , operating system) can be provided to create and edit offers 
and labels and to manage the same. The editor can also be used to create 
label templates, or "templates." A label template contains one or more offers, 
but has no document association. Otherwise, a label template is similar to a 
label. Templates can be used, an reused, as is or edited prior to being 
associated with content to facilitate the creation of labels. For example, 
common combinations of offers can be used as a template to reduce the need 
to create a new label each time the combination of offers is needed. 

Fig. 3 illustrates label editor 300 of the preferred embodiment capable 
of creating and manipulating offers, creating and manipulating label 
templates, and creating and manipulating labels. Further, editor 300 provides 
object oriented managing functions as described below. Editor 300 includes 
rights module 322 for specifying usage rights 222, conditions module 324 for 
specifying conditions 224, offer module 326 for combining usage rights 222 
and conditions 324 into offers 220, and label module 328 for combining one or 
more offers 220 and associating the same with content to define labels 200. 
User interface module 330 provides a graphical user interface for each of the 
other modules as described in detail below. 

User interface module 330 presents the editor, i.e., a person creating, 
editing, or managing offers and labels, with a screen display window where all 
existing labels are listed as described below. Menu items will allow the user to 
create a new label or to edit/copy/delete and otherwise manage a selected 
label or offer or a selected group of labels and or offers. Labels and offers 
can be represented as graphical objects, i.e. icons, and the user can either 
select an existing icon and select an "edit" command or select the "new" 
command to create a new label or offer. 

Assuming a new offer is to be created and the user has selected the 
"new" command, the user is presented with the "new offer" screen illustrated 
in Fig. 4. In this screen, the user will be able to enter the name of the offer in 
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field 406. For example a descriptive name such as "view and print for one 
dollar" can be used. As will become apparent below, the functionality of rights 
module 322, conditions module 324, and offers module 326 are presented 
through user interface module 330 to permit creation and editing of offers 220. 

Pull down menus 402 each include a list of various predetermined 
rights to permit the user to select from the lists one or two usage rights or 
combinations of usage rights. Of course, there can be more than two pull 
down menus 402 to permit a more flexible selection of usage rights. Usage 
rights in the list can include "PRINT," "COPY," "VIEW," "DISTRIBUTE," or any 
other manner of use. Also, each list can include combinations of rights, such 
as "PRINT and VIEW." Similarly, pull down menus 404 each include lists of 
various predetermined conditions to permit the user to select from the lists 
conditions or combinations of conditions. It can be seen that the conditions 
lists are divided into a "FEE" list, a "TIME" list, and an "ACCESS" list. Of 
course, these lists can be combined or segregated further to include other 
lists. Fees can include various monetary amounts, times can include various 
time periods (such as one month after purchase), and access can include 
various persons, groups, or everyone. It can be seen that the combination of 
selections from pull down menus 404 can be used to flexibly define 
conditions, such as "upon payment of $1.00, anyone can use the content in 
accordance with the usage rights for an unlimited time period" as in for 
example Fig. 4. An icon corresponding to an existing offer can be "opened" 
by double clicking with a mouse for example, to present screen 400 and 
permit rights and conditions to be edited by making selections from pull down 
menus 402 and 404. 

Once offers 220 are created, they can be managed like any other kind 
of objects and manipulated to create labels 200 through label module 328 
and user interface 330. Fig. 5 illustrates a display screen for selecting offers 
220, in a graphical manner, bundling the offers, and associating the bundle 
with content to create labels 200. In the example of Fig. 5, there are four 
offers 220, each represented by an icon in list window 502 and having a 
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descriptive name. Of course, there can any number of offers 220 and they 
can be displayed in any manner, such as in the form of a list, a directory tree, 
or the like. User interface module 330 is operative to permit the user browse 
through offers 220 and "open" offers 220 examine the conditions and rights 
thereof, through a display similar to that in Fig. 4, for example. Creation of 
label 200 can be accomplished by "dragging" one or more desired offers 220 
into offers window 504 representing a "rights label container." Drop down 
menus 506 can be used to specify the filename of content to be associated 
with the offers, the portion of the content corresponding to the offers, and 
metadata relating to the content. Note that the drop down menu 506 
corresponding to metadata is merely a generic representation for the sake of 
simplicity. However drop down menus or data entry fields for "author," "title," 
"publication date," or any other specific metadata can be provided. Editing of 
Labels 200 can be accomplished in a similar manner by selecting icons 
representing labels 200 to open a window similar to that of Fig. 5. Opening 
one of offer icons 220 will display a screen similar to that of Fig. 4 for editing 
offers 220. Label 200 can be can saved as and object by entering a 
descriptive name in field 508 and selecting a "save" command. 

User interface module 330 can present the user with sections through 
pull down menus or lists, browse boxes, fields, buttons, or any other interface 
for selecting or specifying the various values. Labels 200 can be saved, 
copied, moved and the like, as an object, similar to any type of file or object. 
The model of the preferred embodiment provides a level of abstraction that 
shields, the editor from computer code. However, labels 200 actually are 
comprised of some type of underlying computer readable file having code, 
data, grammar, or the like, all referred to as "code" herein. For example, the 
underlying code can be in the XrML ™ grammar or in the grammar disclosed 
in US patent no. 5,715,403. In some cases, it may be desirable to have 
access to this computer readable code of labels 200 to manipulate labels 200 
in various ways. 
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Fig. 6 shows a screen presented by user interface module 330 for 
facilitating editing the code of label 200. In window 602, the hierarchical 
structure of thef file named "license" and corresponding to a label 200 is 
presented at 602. For the license file can include a work 604, i.e., content, 
that has been encrypted, and corresponding signatures or keys 606 for each 
work. A description of the selected work is presented in window 604. Editor 
300 can load files, such as XrML files and check their syntax and semantics. 
Also, editor 300 can be used to manipulate the underlying files to label 200 to 
permit more flexible creation of labels. For different industries (such as the 
music industry or book publishing industry), different templates can be created 
to customize to the needs of that industry. For example, units used for book 
publishers may be chapters, pages, or volumes, while units used for the 
music industry can be tracks or minutes. For each industry, one general 
purpose template that covers the conventional parameters can be used as the 
default template. By using the hierarchical, i.e., free, structure of Fig. 6, one 
node can be copied to another node, making the changes in the relevant 
fields much easier and faster. For the management of the labels 200 (for 
example, finding expired labels 200), labels 200 can be selected in order by 
issue date or expiration date as described below. 

Upon opening file user interface module 330 displays a code editor 
screen. Fig. 7 shows an example of a screen of a code editor presented by 
user-interface module 330, which has two settings: "Simple Edit" and 
"Advanced Edit." When "Simple Edit" is selected a simple menu interface 
700, is displayed for managing labels 200, as shown in Fig. 7. The simple 
interface includes display fields for the label name, the URL of the label, 
rights, fees, and metadata. 

Fig. 8 is an example of a screen displayed when advanced edit is 
selected. It can be seen that the code, XrML code in the preferred 
embodiment, is displayed in an edit window for direct editing with a 
conventional text editor interface or the like. This permits a "hands on" 
approach to label editing that is very flexible and leverages the full power of 
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the code used for creating labels 200. Only a potion of the code is illustrated 
in Fig. 8. It can be seen however, that the code includes metadata, a key, 
and other information in the XrML format. 

Fig. 9 illustrates another screen displayed by user interface module 
330 for management of labels 200. Labels 200 are displayed as a list of label 
names. The list can be sorted based on the date or any other parameter in 
the corresponding label 200. Label searches can be conducted by title and/ 
or date of last modification. Some or all labels can be selected, highlighted, 
edited, or deleted. For multiple selections, the same settings are applied to all 
selected labels to accomplish batch processing on labels. For example, in 
batch processing, all prices of similar books can be set at $10.00, 
simultaneously. Editing can be accomplished through screens similar to 
those descried above. Labels 200 can be organized in folders, as noted 
above. When an offer 220 or rights template is applied to a folder, all labels 
200 inside the folder will be associated with that offer or template. 

The interface and model of the preferred embodiment offers multiple 
advantages over conventional systems. For example, the process of 
preparing labels can be automated by assigning an offer or template to a label 
container, adding content and metadata to the container in the manner 
described above. The container can be in the form of a folder or window and 
the objects can be dragged into the folder or window. 

Further, content preparation functions can be integrated into existing 
applications (for example, into a DocuShare™ application where the content 
is "prepared" on its way to the repository). Another example is "preparation- 
on-the-fly" for "just-in-time" publishing applications. Since labels, offers, and 
templates are in the form of objects, they can be easily integrated with 
existing applications. Information in the label, particularly the metadata can 
be indexed for additional functionality. The index can be searchable. Search 
results point back to the label and to the document it associates with. The 
general index can be the basis of a portal for content. This permits very 
flexible searching and distribution of content within a DRM system. Also, 
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rights can be delegated. For example, a publisher can give a distributor 
limited distribution for content merely by assigning the publishers label is to 
the distributor, but with limitations. 

While a preferred embodiment of the invention has been described in 
detail above, it should be recognized that other forms, alternatives, 
modifications, versions and variations of the invention are equally operative 
and would be apparent to those skilled in the art. The disclosure is not 
intended to limit the invention to any particular embodiment, and is intended to 
embrace all such forms, alternatives, modifications, versions and variations. 
Accordingly, the true scope of the invention is defined by the appended claims 
and legal equivalents. 
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